Multisigning - a protocol for robust multiple party digital signatures

ABSTRACT

Embodiments describe a system and/or method for multiple party digital signatures. According to a first aspect a method comprises establishing a first validity range for a first key, establishing a first validity range for at least a second key, and determining if the validity range of the first key overlaps the first validity range of the at least a second key. A certificate is signed with the first validity range of the first key and the first validity range of the at least a second key if the validity ranges overlap. According to another embodiment, signage of the certificate is refused if the first validity range of the first key does not overlap with the first validity range of the at least a second key.

CLAIM OF PRIORITY UNDER 35 U.S.C. §119

The present Application for Patent claims priority to ProvisionalApplication No. 60/667,512 entitled “Method and System for ManagingRobust Multiple Party Digital Signatures”, filed Mar. 31, 2005 andassigned to the assignee hereof and hereby expressly incorporated byreference herein.

BACKGROUND

I. Field

The following description relates generally to data protection and moreparticularly to multiple party digital signatures.

II. Background

When a mobile device downloads data (or has data pushed to it in somefashion), it makes an assessment of such data's trustworthiness. This isparticularly important for executable data or code, for example.Conversely, if an attacker can convince a device that malicious data istrustworthy such attacker has a way of subverting the device'sintegrity.

The creation of digital signatures by use of public key techniques istypically utilized to ensure trustworthiness of data. Typically, aprivate key is used to generate a signature, the authenticity of whichmay then be verified by using the conjugate public key. Public keys arecommonly transmitted and stored in certificates, which bear the keyitself and associated validity and policy meta-information, and whichare signed by a higher order certification authority. The public key ofeach certification authority may also be stored in a certificate,thereby implying a chain of trust and a certification hierarchy.

A private key is compromised whenever it is disclosed to unauthorizedparties or used in an unauthorized way. Once a key is compromised, thechain of trust is broken. Additionally, a private key may be lost, andtherefore rendered unusable. In both scenarios, the key should berevoked, and a new key generated.

If a single key is used to sign blocks of data, then a single compromisewill allow an attacker to exploit the system. If the signer becomesaware of the compromise, then the key may be revoked. However, there areisolated environments (such as bootstrap loaders) that may not havereal-time access to certificate revocation information. Furthermore, ifthe compromise occurs because the signer has “turned rogue,” there is noeffective countermeasure.

Once a mobile device has been compromised, it may not, or it may bedifficult to, be returned to a trustworthy state without physical accessto the device. In the case of cell phones, for example, the cost ofrecalling devices after a widespread security breach is immense.Furthermore, the attacker may be in physical possession of the deviceand thus has no motivation to return the device to a trustworthy state.

Therefore, a high-level assurance of the trustworthiness of data on amobile device, at not only download time but also whenever it is used,is needed. While contemporary digital signature techniques go some wayto solving this problem, they do not provide the necessary assuranceunder certain conditions. For example, when a mobile device is bootingit has no access to a network and hence no access to revocationinformation, however the integrity of the bootstrap mechanism isfundamental.

In addition, there are multiple legitimate stakeholders involved indetermining what data should be trusted by a mobile device. Assurancemechanisms need to account for multiple authorities, and furthermoreaccount for the case where an authority acts improperly.

SUMMARY

The following presents a simplified summary of one or more embodimentsin order to provide a basic understanding of some aspects of suchembodiments. This summary is not an extensive overview of the one ormore embodiments, and is intended to neither identify key or criticalelements of the embodiments nor delineate the scope of such embodiments.Its sole purpose is to present some concepts of the describedembodiments in a simplified form as a prelude to the more detaileddescription that is presented later.

According to a feature is a method for multiple party digitalsignatures. The method includes establishing an initial validity rangefor a first key, establishing a first validity range for at least asecond key, and determining if the initial validity range of the firstkey overlaps with the first validity range of the at least a second key.The method further includes signing a certificate within the initialvalidity range of the first key and the first validity range of the atleast a second key if the validity ranges overlap. Signage of acertificate is refused if the initial validity range does not overlapwith the first validity range. The method can further includeestablishing a secondary validity range that is disjoint from theinitial validity range, and establishing a second validity range that isdisjoint from the first validity. A certificate is signed with thesecondary validity range of the first key and the second validity rangeof the at least a second key if the respective validity ranges overlap.

According to another embodiment is a method of verifying multiple partydigital signatures. The method includes signing a block of data bymultiple parties, verifying the block of data with a correct number ofverified signatures, and determining if the number of verifiedsignatures satisfies a verification policy. If the number of verifiedsignatures satisfies the verification policy, the block of data isdetermined trustworthy. If the number of verified signatures does notsatisfy the verification policy, the block of data is untrustworthy. Thenumber of verified signatures that satisfies the verification policy isa predefined number of signatures equal to or less than the number ofparties that signed the block of data.

According to another embodiment is a system for creating a digitalsignature. The system includes a processor that creates a public key anda corresponding private key, a publisher component that publishes acertificate containing the public key, and an annotation component thatannotates the published certificate with an enforcement range. A startevent and an end event define the enforcement range. The processor cancreate subsequent public and private key pairs, the publisher componentpublishes subsequent certificates containing such respective publickeys, and the annotation component annotates the subsequent certificateswith respective start events and end events.

According to a further embodiment is a system for digital signatures.The system includes a component that creates an initial validity rangefor a first key, a component that creates a first validity range for atleast a second key, and a component that determines if the validityrange of the first key overlaps the first validity range of the at leasta second key. The system can further include signing a certificate withthe initial validity range of the first key and the first validity rangeof the at least a second key if the validity ranges overlap. Alsoincluded is a system for refusing to sign a certificate if the initialvalidity range of the first key does not overlap with the first validityrange of the at least a second key. According to another embodiment thesystem also includes a component for creating a subsequent validityrange for the first key that is disjoint from the initial validityrange, and a component for creating a second validity range for thesecond key that is disjoint from the first validity range.

According to yet another embodiment is a computer readable medium havingcomputer executable instructions for signing a certificate with a firstkey, second key and third key. The first key has a predetermined usagerange. The second key has a predetermined usage range that overlaps thepredetermined usage range of the first key. The third key has apredetermined usage range that overlaps the predetermined usage rangesof the first and second keys. The computer readable medium further hascomputer-executable instructions for certifying the certificate whilethe predetermined usage ranges of the first key, second key and thirdkey are valid.

According to a further embodiment is a processor that executesinstructions for multiple party signatures. The instructions includeestablishing a range in which a certificate is valid based upon aplurality of signatures that have predetermined ranges, monitoring thepredetermined range and invalidating the certificate upon expiration ofat least one of the plurality of predetermined ranges of the pluralityof signatures.

To the accomplishment of the foregoing and related ends, one or moreembodiments comprise the features hereinafter fully described andparticularly pointed out in the claims. The following description andthe annexed drawings set forth in detail certain illustrative aspects ofthe one or more embodiments. These aspects are indicative, however, ofbut a few of the various ways in which the principles of variousembodiments may be employed and the described embodiments are intendedto include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a digital signature system.

FIG. 2 is a block diagram of a multiple party signatures system.

FIG. 3 illustrates validity ranges associated with a multiple partydigital signature system.

FIG. 4 illustrates a hierarchy protocol for multiple party digitalsignatures.

FIG. 5 is a hierarchy protocol for multiple party digital signatures.

FIG. 6 is a flow diagram of a methodology for creating a valid signatureauthentication range for different keys for use with multiple partydigital signatures.

FIG. 7 is a flow diagram of a methodology for generating consecutivevalidity ranges for a plurality of keys for use with multiple partydigital signatures.

FIG. 8 is a flow diagram of a methodology for establishing consecutivevalidity ranges for a single key for use with multiple party digitalsignatures.

FIG. 9 is a flow diagram of a methodology hierarchy for multiple partydigital signatures.

FIG. 10 is a flow diagram of a methodology for verification of multipleparty digital signatures.

FIG. 11 is an exemplary communication system that can operate in awireless environment.

GLOSSARY OF TERMS

Blob—Refers to a block of data to be signed.

Certificate—A public key and associated annotations, signed by acertification authority.

Compromise—Refers to unauthorized use, or potential unauthorized use, ofa private key.

Digital Signature—A unique digest of a blob, computed using the privatekey of the signer.

Multisigning—A protocol whereby multiple parties independently sign ablob in such a way that the blob can be verified without certificaterevocation information.

OpenPGP—The web of trust public key certificate standard.

Private Key—Refers to a secret half of a public key pair, typically usedto generate signatures.

Public Key—Refers to a publishable half of a public key pair, typicallyused to verify signatures.

Revocation—Refers to a notification that a key is no longer to betrusted.

Validity Range—The contiguous time frame for which a certificate isnominally valid.

X.509—A hierarchical public key certificate standard.

DETAILED DESCRIPTION

Various embodiments are now described with reference to the drawings. Inthe following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of one or more aspects. It may be evident, however, thatsuch embodiment(s) may be practiced without these specific details. Inother instances, well-known structures and devices are shown in blockdiagram form in order to facilitate describing these embodiments.

As used in this application, the terms “component,” “system,” and thelike are intended to refer to a computer-related entity, eitherhardware, firmware, a combination of hardware and software, software, orsoftware in execution. For example, a component may be, but is notlimited to being, a process running on a processor, a processor, anobject, an executable, a thread of execution, a program, and/or acomputer. By way of illustration, both an application running on acomputing device and the computing device can be a component. One ormore components can reside within a process and/or thread of executionand a component may be localized on one computer and/or distributedbetween two or more computers. In addition, these components can executefrom various computer readable media having various data structuresstored thereon. The components may communicate by way of local and/orremote processes such as in accordance with a signal having one or moredata packets (e.g., data from one component interacting with anothercomponent in a local system, distributed system, and/or across a networksuch as the Internet with other systems by way of the signal).

With reference now to the drawings, FIG. 1 is a block diagram of asystem 100 that provides a digital signature. A digital signature is away of authenticating that data is received from the true originator andthat the data is trustworthy. System 100 includes a user device 102 anda certificate authority 104. User device 102 may be implemented in aportable device, a portable phone, a personal data assistant, a personalcomputer (desktop or laptop), a moving vehicle (autos, trucks, ships,etc.), or other electronic devices. Certificate authority 104 may beimplemented by entities such as banks, cellular service providers,security service providers, or other trusted third parties. Althoughonly one certificate authority 104 is shown, it should be appreciatedthat there may be one or more certificate authorities.

User device 102 includes a processor 106 that generates cryptographickeys, a publisher component 108 that publishes a certificate 112, and anannotation component 110 that annotates the published certificate withnecessary information. Cryptographic keys include a private key and acorresponding public key. The private key is usually retained in userdevice 102 to maintain such key's secrecy while the public key ispublished and utilized for verification purposes and stored incertificates.

Publish component 108 allows the owner of user device 102 to publish acertificate 112 containing an associated public key 114. Public-keycertificate 112 is a digitally signed statement that certifies orvalidates that the public key belongs to the sender and associates alevel of confidence or trustworthiness to the information. Certificateauthority 104 may also sign certificate 112.

Annotation component 110 annotates public key 114 with a start timestampand an end timestamp, or validity range. Public key 114 is valid onlyduring such validity range. It is not necessary that the timestamps berelated to real time, although they may be. The validity range could bea numbered sequence or a range that is generated by a hash function. Therange can be temporal-based, numerical-based, or based on any othercriteria, provided there is a system and/or method for determining whenthe validity range starts and ends. For example, time can be utilized aspart of the X.590 standard. The X.509 standard defines the informationthat can go into a particular certificate and describes the data formatof the certificate. It should be noted that the various embodimentsdescribed herein could be implemented by a plurality of public keycertification standards, including X.509 and OpenPGP, which supportvalidity ranges and revocation mechanisms.

User device 102 can generate a sequence of keys and certificates for agiven purpose over time. Successive keys replace those keys that haveexpired or that have been revoked. However, each key should have avalidity range that is disjoint from the validity range of eachpreceding and successive key. In other word, no validity ranges shouldoverlap. For example, a first validity range starts on January 1 andends on January 7, if a second validity range starts on January 8 andends on January 13 they are disjoint. However, if the second validityrange begins on January 6, it is invalid and cannot be associated withthe first validity range because the validity ranges are joined.

Each key is only to be utilized for the pre-determined lifetime(validity range). This allows for regular expiration of keys and isgenerally unrelated to a timestamp of certificate 112. The validityrange of the key does not have to be contained in certificate 112,although it can be included in certificate 112. Additionally, validityrange of the key may not be determinable from the timestamp of thecertificate.

If a private key, stored in user device 102, is expired, it should bedestroyed to reduce the chances of the old keys being compromised. Newsigning keys are generated to replace expired keys and can be created onor before the time of expiration.

Referring now to FIG. 2, a block diagram of a multiple party digitalsignature system 200 is illustrated. System 200 includes a first userdevice 202 and a second user device 204 and a certificate 206 signed byfirst and second user devices 202 and 204 and/or a certificate authority(not shown). While only two user devices are shown, it will beunderstood by those skilled in the art that there may be more than twodevices. Each user device includes respective processors 208 and 214that generate cryptographic keys, publish components 210 and 216 thatpublish a certificate for multiple party digital signatures, andannotate components 212 and 218 that annotate information to thecertificate.

Multiple parties, through respective user devices 202 and 204, digitallysign certificate 206 to allow for an assessment of trustworthiness ofdata when that data is to be downloaded or utilized by a user. Thecertificate published by respective user devices 202 and 204 containrespective public keys 220 and 222 with a validity range that includes astart timestamp and an end timestamp. The timestamp associated withpublic key 220 does not have to be identical to the time stamp of publickey 222. However, each respective validity range should overlap. Forexample, if public key 220 has a validity range from Monday to Wednesdayand public key 222 has a validity range from Monday to Thursday, thereis sufficient overlap. However, if public key 222 has a validity rangefrom Thursday to Friday, the overlap is not sufficient.

There are several ways a certificate can be signed with more than onesignature, known as multisigning. A few multisigning techniques arecosigning, countersigning, and cross signing and will be brieflydiscussed.

The most basic form of multisigning is cosigning. In cosigning, there isa signature of first key “A” with a message on it and a signature ofsecond key “B” with a message on it. When cosigning is used, each partyis independent, that is, each party is not aware that the other party issigning the certificate.Sig_(A)(m), Sig_(B)(m)

Another type of multisigning is countersigning. This is typically usedon digital authorization services, such as a commercial service. Thereis a signature of A with a message, and a signature of B with a message,off the signature and message of A. Essentially, B is attesting to thefact that A signed the message.Sig_(A)(m),Sig_(B)(m,Sig_(A)(m))

Cross signing is another type of multisigning where there is a signatureof A with a message and an indicator that B should also sign.Essentially, what it indicates is that A is going to sign the messageand knows it should also be signed by B. A is further concluding thatA's signature is optional.Sig_(A)(m,[A],B)

B would also sign a signature, similar to that described with referenceto A above, concluding B's signature is optional.Sig_(B)(m,A,[B])

While A does not have to include [A] and B does not have to include [B],including such indications provides that the actual content both A and Bsign are the same. Having the same content is a verification issue. If Aand B do not include themselves, the respective signatures would be asindicated below.Sig_(A)(m,B)Sig_(B)(m,A)

While the above are examples of multisigning, a plurality of multipleparty signature schemes can be utilized according to the embodimentsdisclosed herein.

Each blob, or block of data, is signed by multiple parties, therebycreating a signature set of <n> signatures. Each signature isindependent and may be generated in any order, or even at asubstantially similar time.

To verify a blob, each <n> signature is independently verified by usingthe appropriate certificate. The number of correctly verified signaturesis defined as <v>, where <v> is greater than or equal to zero and lessthen or equal to <n>:0≦<v>≦<n>

The minimum number of correct signatures that will satisfy theverification policy is defined as <m>. That is, not every verifiedsignature, <v>, need to be retrieved to satisfy verification policy.Verification succeeds when <v> is greater than or equal to <m>guaranteeing that at least <m> signers have independently verified theblob.<V>≧<m>

Additionally the intersection of the valid time windows of the <v>certificates is a non-zero range. This guarantees that at the time eachsignature was generated, no revocation notice of one or more of theother keys had been received by the signer or user device.

In a simple case where the minimum number of correct signatures thatwill satisfy the verification policy, <m>, is equal to the number ofsignatures that signed the blob, <n>, all signatures need to be correct.This is expressed as:<m>=<n>

This provides maximal assurance. However, it also means that a singlerevocation prevents further signing until the <n> signers haveregenerated keys. More generally, the condition is less stringent whenthe minimum number of correct signatures that will satisfy theverification policy, <m>, is less than the number of signatures thatsigned the blob, <n>.<m><<n>

In this case, the protocol permits there to be a number ofcontemporaneous revocations equal to the number of signatures <n> minusthe number of <m> correct signatures without preventing further signingfrom taking place.(<n>−<m>)

Verification does not necessitate access to a particular type of timekeeping, as the time comparisons are relative and the timestamps areagainst an arbitrary time base. However, a verifier may choose to applyreal time constraints as part of its policy if the timestamps aredefined to be relative to real time, or if additional time informationis carried in the certificate.

Whenever a key is revoked, the signers should regenerate new keys thatdo not overlap with the revoked key, known as compromise recovery. Forexample, at substantially the same time as there is one more signer thanthe total number of signatures, <n>, minus the number of <m> signers,overlapping keys are revoked, and a new key is generated to allowsigning to continue.(<n>−<m>+1)

Given that the validity range of new keys should not overlap with thevalidity range of a revoked key, the certificate can be generated withan inception timestamp that indicates a start and end time that takesplace in the future. In general, this is not a problem as timestamps aretreated by this protocol as purely relative values. That is to say, thevalidity range can be based upon a plurality of values, provided thereis a mechanism to determine the start and end of the range and if therelative validity ranges of the multiple signers overlap.

FIG. 3 is an illustration of validity ranges associated with respectivekeys. Line 300 is a time representation of a validity range, and realtime is used for simplicity of illustration only and not by way oflimitation. Two signers illustrated as “A” and “B,” with A's keysrepresented above line 300 and B's keys represented below line 300.

A has five validity ranges represented as keys K_(A)-0, K_(A)-1,K_(A)-2, K_(A)-3, and K_(A)-4. B has three validity ranges representedas keys K_(B)-0, K_(B)-1, and K_(B)-2. As illustrated, K_(A)-0 andK_(B)-0, have substantially similar validity ranges with a starttimestamp at 302 and an end timestamp at 304. Thus, the respectivevalidity ranges K_(A)-0 and K_(B)-0 are overlapping and can generate avalid signature of the certificate during that validity range.

The respective validity ranges K_(A)-1 and K_(B)-1 are similarlysufficiently overlapping. K_(B)-1 has a start timestamp 306 that isbefore K_(A)-1's start timestamp 308. However, K_(A)-1's end timestamp310 is before K_(B)-1's end timestamp 312. However, because K_(B)-1'svalidity range sufficiently overlaps K_(A)-1's validity range it allowsfor generation of a valid signature. Thus, the validity ranges do nothave to be equally overlapping or have the same start timestamp and sameend timestamp to be valid.

K_(A)-2 and K_(B)-2 illustrate partially overlapping validity ranges.K_(B)-2 has a start timestamp 314 that is before K_(A)-2's starttimestamp 316 and K_(B)-2's end timestamp 318 expires before K_(A)-2'send time stamp 320. The overlapping range in which a valid signature canbe generated is between K_(A)-2's start time stamp 316 and K_(B)-2's endtime stamp 318.

K_(A)-3 and K_(B)-3 illustrate non-overlapping validity ranges. K_(A)-3has a start time stamp 322 and an end time stamp 324 that are distinctfrom K_(B)-3's start time stamp 326 and end time stamp 328. Thus,K_(A)-3 and K_(B)-3 are not overlapping and generation of a validsignature for A and/or B is not possible during validity ranges K_(A)-3and K_(B)-3.

It should be noted that the validity ranges should be disjoint. Forexample, validity ranges K_(A)-0, K_(A)-1 and K_(A)-2 are disjoint.However, validity ranges K_(A)-4 and K_(A)-5 are not disjoint. That isthe validity ranges K_(A)-4 and K_(A)-5 overlap at 330. Thus, A cannotvalidly sign a certificate during validity ranges K_(A)-4 and K_(A)-5.

Since the validity range of multiple party signatures should overlapduring the same validity range, signatures that do not overlap cannotcreate a valid signature. For example, K_(A)-0 cannot create a validsignature with K_(B)-1 and/or K_(B)-2. Likewise, K_(B)-1 cannot create avalid signature with K_(A)-0 and/or K_(A)-2. The other keys operate in asimilar fashion.

Referring now to FIG. 4 a certification hierarchy 400 is illustrated.Certification hierarchy 400 includes parent key K_(A)-0 and child keysK_(A)-1, K_(A)-2, and K_(A)-3 contained within the validity range ofparent key K_(A)-0. While a certification hierarchy is in force, thevalidity range of each child key K_(A)-1, K_(A)-2, and K_(A)-3 isentirely contained in the validity range of its parent K_(A)-0. Childkeys K_(A)-1, K_(A)-2, and K_(A)-3 that do not meet this condition arenot trusted. A compromise at any point in the hierarchy necessitates therevocation and regeneration of that key. The new key, as per a keymanagement criteria, is assigned a validity range that does not overlapwith the previous key. Thus, the child keys are also recursively revokedand regenerated.

It can be argued that the more often a key is used, the more it isexposed to potential compromise. Therefore, a certification hierarchy ofseveral levels can be utilized when implementing this protocol. Keys ata higher level are longer lived, while keys at lower levels areregenerated more frequently. For example, a three level hierarchy mayuse root keys with a lifetime of one decade, intermediate keys with anintermediate level lifetime of one year, and interval duration keys witha lower level lifetime of one month. In this case, the maximum time anundetected compromise of a lower level key (arguably the most exposed)could be exploited for is one month.

With continuing reference to FIG. 4, an entity, A, has validity rangesK_(A)-0, K_(A)-1, K_(A)-2 and K_(A)-3 represented above line 400. Anentity, B, has validity ranges K_(B)-0, K_(B)-1, K_(B)-2 and K_(B)-3represented below line 400. It should be appreciated that line 400represents a value that can be used for validity range purposes and byway of illustration and not limitation, is described as a time line. Forsimplicity purposes, the validity ranges of A and B are shown asencompassing the same range, however, it should be appreciated that thevalidity ranges may be different, provided they sufficiently overlap.

Entity A of the hierarchy 400 includes a root key K_(A)-0, anintermediate key K_(A)-1, and interval duration keys K_(A)-2 andK_(A)-3. Similarly, B has a root key K_(B)-0, an intermediate keyK_(B)-1, and interval duration keys K_(B)-2 and K_(B)-3. The root keysand intermediate keys can also reside at a server when variouscomputations are performed. Root keys K_(A)-0 and K_(B)-0 are atrespective primary levels and associated with respective certificateauthorities. Root keys K_(A)-0 and K_(B)-0 can be valid for asubstantially indefinite range of time, as illustrated at starttimestamp 402 and end timestamp 404.

Validity ranges K_(A)-1 and K_(B)-1 are of a lesser duration and havestart timestamp 406 and end timestamp 408. K_(A)-1 and KB-1 aresufficiently included in the validity range of K_(A)-0 and K_(B)-0. Thatis to say, the validity ranges of K_(A)-0 and K_(B)-0 are longer induration than the validity ranges of K_(A)-1 and K_(B)-1. For example,root keys K_(A)-0 and K_(B)-0 can have a validity range of ten years andintermediate keys K_(A)-1 and K_(B)-1 can have validity ranges of oneyear, for example.

The validity ranges of duration keys K_(A)-2, K_(A)-3, K_(B)-2, andK_(B)-3 fall within respective validity ranges of K_(A)-1 and K_(B)-1.The duration keys can have a validity range less than the validity rangeof intermediate keys, for example, one week. Thus, because they areincluded in the validity range of both the intermediate key(s) androot(s), the certification hierarchy is satisfied.

Certificate hierarchy can be supported by various standards, includingX.509 and OpenPGP. However, the embodiments disclosed herein can beimplemented utilizing a plurality of hierarchy standards and is notlimited to X.509 and/or OpenPGP.

A web of trust is more general than a strict certification hierarchy. Ingeneral, each certificate can have more than one certifier, and thetrust relationships form a directed graph. This protocol can beimplemented with a web of trust by applying the constraint that thevalidity range of certificates are entirely contained by those of itscertifiers. This implies that the trust web is acyclical unless thevalidity ranges of the keys are congruent. OpenPGP is an example of onestandard that supports webs of trust and can be utilizing according toone or more of the disclosed embodiments.

Referring now to FIG. 5 a hierarchy protocol for multiple partysignatures is illustrated. The hierarchy is discussed in relation to afirst entity, A, that has a root key K_(A)-0, intermediate key K_(A)-1,and three duration keys K_(A)-2, K_(A)-3, and K_(A)-4. If acertification hierarchy is in force, the validity range of eachcertificate K_(A)-2 and K_(A)-3 is entirely contained in the validityrange of its parent K_(A)-1 and K_(A)-0, and is thus valid. However, thecertificate of key K_(A)-4 is outside the hierarchy of parent keyK_(A)-1 and thus, is not a valid certificate under a hierarchy protocol.It should be appreciated that the range from 502 to 504 can be verifiedby key K_(A)-1 itself and/or a duration key.

While the figures and examples discussed herein refer to two sets ofkeys and/or three levels of keys in a certificate hierarchy, it shouldbe appreciated that there may be more than two sets of keys and more (orless) than three key levels.

Referring to FIGS. 6-10, methodologies relating to multiple partysignatures are illustrated. While, for purposes of simplicity ofexplanation, the methodologies are shown and described as a series ofacts, it is to be understood and appreciated that the methodologies arenot limited by the order of acts, as some acts may, in accordance withthese methodologies, occur in different orders and/or concurrently withother acts from that shown and described herein. For example, thoseskilled in the art will understand and appreciate that a methodologycould alternatively be represented as a series of interrelated states orevents, such as in a state diagram. Moreover, not all illustrated actsmay be required to implement the following methodologies.

Each signer holds a private key, and publishes a certificate containingthe associated public key. Each certificate annotates its key with astart timestamp and an end timestamp. The key is generally valid only inthe range between these two instances, known as the validity range.

Signers typically generate sequences of keys and certificates for agiven purpose over time, with successive keys replacing those expired orrevoked. There is no need for the timestamps to be related to real time(although they may be). However, keys in a sequence should possessdisjoint validity ranges. In other words, none of the validity rangesshould overlap. The signers should cooperate when generating keys toensure that the set of keys used contemporaneously do possessoverlapping validity ranges.

Each key is used only for a pre-determined lifetime and keys areregularly expired. Note that the validity range of the key is, ingeneral, unrelated to the certificate's end timestamp. Validity rangeinformation may or may not be carried in the certificate and may or maynot be determinable from the end timestamp. Expired private keys shouldbe destroyed, to reduce the likelihood of old keys being compromised.New signing keys should be generated to replace expired keys; this canhappen on or before the end of the validity range.

If a key is compromised or lost, its owner notifies the other signersthat the key is revoked. Notification may be by a plurality ofmechanisms; a certificate revocation list would be typical. If acertificate revocation is received (and verified), the signer shouldtreat the other key(s) with a validity range overlapping the revoked keyas expired. Corresponding private key(s) should be consequentlydestroyed. This synchronization guarantees that overlapping keys areonly used for signing in the absence of revocation notices.

FIG. 6 is a flow diagraph of a methodology 600 for creating a validsignature authentication range for different keys for use with multipleparty signatures. It should be appreciated that while the flow diagramis discussed with regard to a first key, A, and a second key, B, themethodology supports more than two keys and is not limited as such.

At 602, a validity range is established with regard to key A. Thevalidity range has both a start timestamp and an end timestamp. Aplurality of means can be utilized to establish the validity range andis not limited to a duration of time, although it is easy to think of avalidity range in terms of time. Key A has a public key and anassociated private key. This validity range is associated with thepublic key of a user device and a certificate is signed by such publickey.

At least one other party or entity creates key B, at 604, having apublic key and a private key. A validity range is established for thepublic key of key B with both a start timestamp and an end timestamp. Acertificate is signed by B's public key and associated validity range.

In order for the certificate that is signed by both A and B to be valid,the respective validity ranges should overlap. A determination is madeat 606 whether there is sufficient overlap. That is to say, bothvalidity ranges encompass the same range allowing for toggling orstaggering of the start timestamps and end timestamps. Thus, thevalidity ranges of the keys that sign the certificate do not have to beequal or have the same start timestamp and end timestamp.

If the validity ranges overlap, at 608 the certificate and associateddigital signatures are deemed trustworthy. If, however, there is notsufficient overlap of the validity ranges, the certificate is nottrustworthy and at 610, it is not validated with trustworthy digitalsignatures.

FIG. 7 is a flow diagram of a methodology 700 for generating consecutivevalidity ranges for a plurality of keys for use with multiple partysignatures. At 702 validity ranges for at least two entities are createdwith sufficient overlap, as determined by a methodology, such as the oneillustrated and described with regard to FIG. 6. At 704, a secondvalidity range is established. This second validity range is disjoinedfrom the respective first validity ranges. That is to say, there can beno overlap between first validity range and second validity range. Itshould be noted that a second validity range is created for bothentities to avoid, for example, a first validity range of the firstentity overlapping both a first and a second validity range of thesecond entity. If the first validity range of the first entity isoverlapping both validity ranges of the second entity and one of thekeys is compromised, there is a greater opportunity for the system to beexploited.

At 706 a determination is made whether the second validity ranges ofboth entities overlap, and can be determined in the same manner as theoverlap of the first validity ranges are established. If there is notsufficient overlap, access and signature of the certificate is denied at708.

If sufficient overlap is determined at 706, access and signature of thecertificate is allowed. It should be noted that subsequent validityranges (e.g. third, fourth, fifth, . . . ) can be established andverified in the same manner as that illustrated and described withreference to first and second validity ranges.

FIG. 8 is a flow diagram of a methodology 800 for establishingconsecutive validity ranges for a single key for use with multiple partysignatures. A first and second validity range associated with a firstpublic key is created at 802. The first and second validity ranges havea start timestamp and an end time stamp. While the creation of the firstand second validity ranges is shown at a similar time, it should beunderstood that the creation of the second (and subsequent) validityranges can be created before or at a substantially similar time as avalidity range expires. That is to say, the second validity range shouldbe created at or before the end timestamp of the first validity range.

At 804, a determination is made whether the first and second validityranges are disjoint with separate and distinct validity ranges. That isto say, the first and second validity ranges associated with the samepublic key cannot occur or exist during the same validity range orportion(s) thereof. This may necessitate generating a certificate withan inception timestamp in the future. This is not a problem sincetimestamps are treated as purely relative values.

If at 804 it is determined that the validity ranges are not disjoint,the certificate, represented by the second validity range, is notassociated with a digital signature of this user. If the validity rangesare disjoint, the certificate is digitally signed and can be utilizedfor verification. If there is overlapping, those overlapping keys arerevoked and new keys are regenerated before signing can continue.

At 810, a third, or subsequent validity ranges (e.g. fourth, fifth,sixth . . . ) are created either at or before the time the previousvalidity range expires. The subsequent validity ranges should bedisjoint from previous validity ranges of the preceding validity ranges.

FIG. 9 is a flow diagram of a hierarchy methodology 900 for multipleparty signatures. A root key is created at 902, this root key can bestored on both a user device and on a server. The root key contains astart timestamp and an end timestamp. The root key has a longer validityrange and can be represented by a number of years, for example.

An intermediate key is created at 904, the intermediate key can bestored both on a user device and on a server. The intermediate key hasan associated start timestamp and end timestamp. According to hierarchyprotocol, the validity range of the intermediate key should becompletely contained in the validity range of the root key. Acertificate generated by intermediate key that is not within thevalidity range of the root key, cannot be trusted. Since theintermediate key has a validity range shorter than that of the root key,it can be represented, for example, by month(s).

A duration key at a third level is created at 906. Duration key has astart timestamp and an end timestamp, which should be contained withinthe validity ranges of both the root key and the intermediate key. Ahierarchy having several layers helps to mitigate potential compromisesof the key's integrity. The duration key has a short, expendable timerange, and for purposes of illustration, can be represented by a week.Thus, if the duration key is compromised, the longest that this lowerlevel key (and potentially the most exposed) can be compromised andexploited is for is one week.

At 908, a determination is made whether the root key validity rangecontains the validity range(s) of the intermediate key(s) and if theintermediate key(s) validity range(s) contain the validity range(s) ofthe duration key(s). If no, then at 910 keys with validity rangesoutside the hierarchy cannot be trusted. At this point, that key isrevoked and a new key is generated. However, if the determination at 908is yes, the key can be trusted and at 912 is used to digitally signcertificates.

FIG. 10 is a flow diagram of a methodology 1000 for verification ofmultiple party signatures. At 1002, a blob is signed by multiple partiescreating a signature set of <n> signatures. Each signature is generatedindependently, in any order, and may be generated at a substantiallysimilar time.

At 1004 the blob is verified by <v> signatures where <v> is the numberof correctly verified signatures. Each <V> signature is to beindependently verified by using the appropriate certificate. The correctnumber of signatures can be a number greater than zero and less than orequal to <n>.0≦<v>≦<n>

A determination is made at 1006 whether there are a minimum number ofcorrect signatures <m> that satisfy the verification policy. That is tosay, the verification succeeds if the number of correctly verifiedsignatures <v> is equal to, or more than, the minimum number of correctsignatures <m> necessary to verify the certificate.<V>≧<m>

Additionally, for verification to succeed at the time each signature wasgenerated the signer should not have been notified of revocation of oneor more of the other keys. If the above two conditions are satisfied, at1008, the certificate is trusted. If the conditions are not satisfied,the certificate is not trusted at 1010.

FIG. 11 shows an exemplary wireless communication system 1100. Thewireless communication system 1100 depicts one base station and oneterminal for sake of brevity. However, it is to be appreciated that thesystem can include more than one base station and/or more than oneterminal, wherein additional base stations and/or terminals can besubstantially similar or different for the exemplary base station andterminal described below. In addition, it is to be appreciated that thebase station and/or the terminal can employ the systems (FIGS. 1-3)and/or methods (FIGS. 6-10) described herein to facilitate wirelesscommunication there between. Although the system is primarily describedwithin the context of an orthogonal frequency multiplex modulationsystem, it is to be appreciated that any suitable protocol/system (e.g.,code division multiplex access (CDMA)) may be employed in connectionwith the various embodiments described herein.

Referring now to FIG. 11, on a downlink, at access point 1105, atransmit (TX) data processor 1110 receives, formats, codes, interleaves,and modulates (or symbol maps) traffic data and provides modulationsymbols (“data symbols”). An OFDM modulator 1115 receives and processesthe data symbols and pilot symbols and provides a stream of OFDMsymbols. An OFDM modulator 1120 multiplexes data and pilot symbols onthe proper subbands, provides a signal value of zero for each unusedsubband, and obtains a set of N transmit symbols for the N subbands foreach OFDM symbol period. Each transmit symbol may be a data symbol, apilot symbol, or a signal value of zero. The pilot symbols may be sentcontinuously in each OFDM symbol period. Alternatively, the pilotsymbols may be time division multiplexed (TDM), frequency divisionmultiplexed (FDM), or code division multiplexed (CDM). OFDM modulator1120 can transform each set of N transmit symbols to the time domainusing an N-point IFFT to obtain a “transformed” symbol that contains Ntime-domain chips. OFDM modulator 1120 typically repeats a portion ofeach transformed symbol to obtain a corresponding OFDM symbol. Therepeated portion is known as a cyclic prefix and is used to combat delayspread in the wireless channel.

A transmitter unit (TMTR) 1120 receives and converts the stream of OFDMsymbols into one or more analog signals and further conditions (e.g.,amplifies, filters, and frequency upconverts) the analog signals togenerate a downlink signal suitable for transmission over the wirelesschannel. The downlink signal is then transmitted through an antenna 1125to the terminals. At terminal 1130, an antenna 1135 receives thedownlink signal and provides a received signal to a receiver unit (RCVR)1140. Receiver unit 1140 conditions (e.g., filters, amplifies, andfrequency downconverts) the received signal and digitizes theconditioned signal to obtain samples. An OFDM demodulator 1145 removesthe cyclic prefix appended to each OFDM symbol, transforms each receivedtransformed symbol to the frequency domain using an N-point FFT, obtainsN received symbols for the N subbands for each OFDM symbol period, andprovides received pilot symbols to a processor 1150 for channelestimation. OFDM demodulator 1145 further receives a frequency responseestimate for the downlink from processor 1150, performs datademodulation on the received data symbols to obtain data symbolestimates (which are estimates of the transmitted data symbols), andprovides the data symbol estimates to an RX data processor 1155, whichdemodulates (i.e., symbol demaps), deinterleaves, and decodes the datasymbol estimates to recover the transmitted traffic data. The processingby OFDM demodulator 1145 and RX data processor 1155 is complementary tothe processing by OFDM modulator 1115 and TX data processor 1110,respectively, at access point 1100.

On the uplink, a TX data processor 1160 processes traffic data andprovides data symbols. An OFDM modulator 1165 receives and multiplexesthe data symbols with pilot symbols, performs OFDM modulation, andprovides a stream of OFDM symbols. The pilot symbols may be transmittedon subbands that have been assigned to terminal 1130 for pilottransmission, where the number of pilot subbands for the uplink may bethe same or different from the number of pilot subbands for thedownlink. A transmitter unit 1170 then receives and processes the streamof OFDM symbols to generate an uplink signal, which is transmitted bythe antenna 1135 to the access point 1110.

At access point 1110, the uplink signal from terminal 1130 is receivedby the antenna 1125 and processed by a receiver unit 1175 to obtainsamples. An OFDM demodulator 1180 then processes the samples andprovides received pilot symbols and data symbol estimates for theuplink. An RX data processor 1185 processes the data symbol estimates torecover the traffic data transmitted by terminal 1135. A processor 1190performs channel estimation for each active terminal transmitting on theuplink. Multiple terminals may transmit pilot concurrently on the uplinkon their respective assigned sets of pilot subbands, where the pilotsubband sets may be interlaced.

Processors 1190 and 1150 direct (e.g., control, coordinate, manage,etc.) operation at access point 1110 and terminal 1135, respectively.Respective processors 1190 and 1150 can be associated with memory units(not shown) that store program codes and data. Processors 1190 and 1150can also perform computations to derive frequency and impulse responseestimates for the uplink and downlink, respectively.

For a multiple-access OFDM system (e.g., an orthogonal frequencydivision multiple-access (OFDMA) system), multiple terminals maytransmit concurrently on the uplink. For such a system, the pilotsubbands may be shared among different terminals. The channel estimationtechniques may be used in cases where the pilot subbands for eachterminal span the entire operating band (possibly except for the bandedges). Such a pilot subband structure would be desirable to obtainfrequency diversity for each terminal. The techniques described hereinmay be implemented by various means. For example, these techniques maybe implemented in hardware, software, or a combination thereof. For ahardware implementation, the processing units used for channelestimation may be implemented within one or more application specificintegrated circuits (ASICs), digital signal processors (DSPs), digitalsignal processing devices (DSPDs), programmable logic devices (PLDs),field programmable gate arrays (FPGAs), processors, controllers,micro-controllers, processors, other electronic units designed toperform the functions described herein, or a combination thereof. Withsoftware, implementation can be through modules (e.g., procedures,functions, and so on) that perform the functions described herein. Thesoftware codes may be stored in memory unit and executed by theprocessors 1190 and 1150.

It is to be understood that the embodiments described herein may beimplemented by hardware, software, firmware, middleware, microcode, orany combination thereof. When the systems and/or methods are implementedin software, firmware, middleware or microcode, program code or codesegments, they may be stored in a machine-readable medium, such as astorage component. A code segment may represent a procedure, a function,a subprogram, a program, a routine, a subroutine, a module, a softwarepackage, a class, or any combination of instructions, data structures,or program statements. A code segment may be coupled to another codesegment or a hardware circuit by passing and/or receiving information,data, arguments, parameters, or memory contents. Information, arguments,parameters, data, etc. may be passed, forwarded, or transmitted usingany suitable means including memory sharing, message passing, tokenpassing, network transmission, etc.

What has been described above includes examples of one or moreembodiments. It is, of course, not possible to describe everyconceivable combination of components or methodologies for purposes ofdescribing these embodiments, but one of ordinary skill in the art mayrecognize that many further combinations and permutations of suchembodiments are possible. Accordingly, the embodiments described hereinare intended to embrace all such alterations, modifications, andvariations that fall within the spirit and scope of the appended claims.Furthermore, to the extent that the term “includes” is used in eitherthe detailed description or the claims, such term is intended to beinclusive in a manner similar to the term “comprising” as “comprising”is interpreted when employed as a transitional word in a claim.

1. A method for multiple party digital signatures, comprising:establishing an initial validity range for a first key; establishing afirst validity range for at least a second key; and determining if theinitial validity range of the first key overlaps with the first validityrange of the at least a second key.
 2. The method of claim 1, furthercomprising: signing a certificate within the initial validity range ofthe first key and the first validity range of the at least a second keyif the validity ranges overlap.
 3. The method of claim 1, furthercomprising: refusing signage of a certificate if the initial validityrange of the first key does not overlap with the first validity range ofthe at least a second key.
 4. The method of claim 1, further comprising:establishing a secondary validity range for the first key that isdisjoint from the initial validity range; and establishing a secondvalidity range for the second key that is disjoint from the firstvalidity range.
 5. The method of claim 4, further comprising: revokingthe initial validity range of the first key and the first validity rangeof the at least second key; and determining if the secondary validityrange of the first key and the second validity range for the second keyoverlap.
 6. The method of claim 5, further comprising: signing acertificate with the secondary validity range of the first key and thesecond validity range of the at least a second key if the validityranges overlap.
 7. The method of claim 5, further comprising: refusingcertificate signage if the secondary validity range of the first keydoes not overlap with the second validity range of the at least a secondkey.
 8. The method of claim 1, further comprising providing the initialvalidity range of the first key a start timestamp and an end timestampthat determines the range of the initial validity range; and providingthe first validity range of the second key a start timestamp and an endtimestamp that determines the range of the first validity range.
 9. Themethod of claim 8, further comprising: establishing a secondary validityrange for the first key that has a start timestamp and an end timestampthat is separate from the initial validity range of the first key; andestablishing a second validity range for the second key that has a starttimestamp and an end timestamp that is separate from the first validityrange of the second key.
 10. The method of claim 9, further comprising:establishing a third validity range of the first and second keys beforean expiration of the secondary validity range of the first key and thesecond validity range of the second key.
 11. A method of verifyingmultiple party digital signatures, comprising: signing a block of databy multiple parties; verifying the block of data with a correct numberof verified signatures; and determining if the number of verifiedsignatures satisfies a verification policy.
 12. The method of claim 11,further comprising: trusting the block of data if the number of verifiedsignatures satisfies the verification policy.
 13. The method of claim11, further comprising: denying trust to the block of data if the numberof verified signatures does not satisfy the verification policy.
 14. Themethod of claim 11, the number of verified signatures that satisfies theverification policy is a predefined number of signatures less than thenumber of signers.
 15. The method of claim 14, the number of verifiedsignatures is less than the number of multiple parties that signed thecertificate.
 16. The method of claim 11, revocation of at least one keyassociated with at least one of the multiple parties that signed theblock of data prevents further signing until all multiple parties haveregenerated new keys.
 17. An apparatus for creating a digital signature,comprising: a processor that creates a public key and a correspondingprivate key; a publisher component that publishes a certificatecontaining the public key; and an annotation component that annotatesthe published certificate with an enforcement range.
 18. The apparatusof claim 17, the annotation component establishes a start event and anend event.
 19. The apparatus of claim 18, the start event and the endevent define the enforcement range.
 20. The apparatus of claim 17, theprocessor creates subsequent public and private key pairs and thepublisher component publishes subsequent certificates containing arespective public key.
 21. The apparatus of claim 20, the annotationcomponent annotates the subsequent certificates with respective startevents and end events.
 22. The apparatus of claim 21, the respectivestart events and end events represent respective enforcement ranges. 23.The apparatus of claim 22, the respective enforcement ranges are notrelated.
 24. The apparatus of claim 17, the processor creates subsequentpublic and private key pairs before an expiration of the previousenforcement range.
 25. A system for digital signatures comprising: meansfor creating an initial validity range for a first key; means forcreating a first validity range for at least a second key; and means fordetermining if the initial range of the first key overlaps with thefirst validity range of the at least a second key.
 26. The system ofclaim 25, further comprising: means for signing a certificate with theinitial validity range of the first key and the first validity range ofthe at least a second key if the validity ranges overlap.
 27. The systemof claim 25, further comprising: means for refusing to sign acertificate if the initial validity range of the first key does notoverlap with the first validity range of the at least a second key. 28.The system of claim 25, further comprising: means for creating asubsequent validity range for the first key that is disjoint from theinitial validity range; and means for creating a second validity rangefor the second key that is disjoint from the first validity range. 29.The system of claim 28, further comprising: means for determining if thesubsequent validity range of the first key and the second validity rangeof the second key overlap.
 30. The system of claim 29, furthercomprising: means for signing a certificate with the subsequent validityrange of the first key and the second validity range of the at least asecond key if the validity ranges overlap.
 31. The system of claim 29,further comprising: means for refusing to sign a certificate if thesubsequent validity range of the first key does not overlap with thesecond validity range of the at least a second key.
 32. The system ofclaim 31, further comprising means for providing the initial validityrange of the first key a start timestamp and an end timestamp thatdetermines the range of the first validity range; and means forproviding the first validity range of the second key a start timestampand an end timestamp that determines the range of the first validityrange.
 33. The system of claim 32, further comprising: means forestablishing a subsequent validity range for the first key that has astart timestamp and an end timestamp that is separate from the firstvalidity range of the first signature; and means for establishing asecond validity range for the second key that has a start timestamp andan end timestamp that is separate from the first validity range of thesecond signature.
 34. The system of claim 33, further comprising:establishing a third validity range of the first and second keys beforean expiration of the subsequent validity range and the second validityrange.
 35. A computer readable medium having computer-executableinstructions for: signing a certificate with a first key that has apredetermined usage range; signing the certificate with a second keythat has a predetermined usage range that overlaps the predeterminedusage range of the first key; and signing the certificate with a thirdkey that has a predetermined usage range that overlaps the predeterminedusage ranges of the first and second keys.
 36. The computer readablemedium of claim 35, further comprising computer-executable instructionsfor: certifying the certificate during a validity range of thepredetermined usage ranges of the first key, second key and third key.37. The computer readable medium of claim 35, further comprisingcomputer-executable instructions for: creating a fourth key with apredetermined usage range that does not contain the usage range of thefirst key; creating a fifth key with a predetermined usage range thatdoes not contain the usage range of the second key; and creating a sixthkey with a predetermined usage range that does not contain the usagerange of the third key.
 38. The computer readable medium of claim 37,the first, second, third, fourth, fifth and sixth keys are durationkeys.
 39. The computer readable medium of claim 38, further comprising:an intermediate key with a predetermined usage range that is longer thanthe predetermined usage ranges of the duration keys and wherein theduration keys are included in a hierarchy of the intermediate key. 40.The computer readable medium of claim 39, further comprising: a root keywith a predetermined usage range that is longer than the predeterminedusage range of the intermediate key and wherein the intermediate key isincluded in a hierarchy of the root key.
 41. The computer readablemedium of claim 40, further comprising computer-executable instructionsfor: denying certification of the certificate if the intermediate key isnot included in the hierarchy of the root key; and denying certificationof the certificate if the duration keys are not included in thehierarchy of the intermediate key.
 42. The computer readable medium ofclaim 37, further comprising computer-executable instructions for:determining if the predetermined usage ranges of the fourth, fifth andsixth keys overlap.
 43. The computer readable medium of claim 38,further comprising computer-executable instructions for: validating asecond certificate if the predetermined usage ranges of the fourth,fifth and sixth keys overlap.
 44. The computer readable medium of claim38, further comprising computer-executable instructions for:invalidating a second certificate if the predetermined usage ranges ofthe fourth, fifth and sixth keys do not overlap.
 45. A portablecommunication device comprising the computer readable medium of claim35.
 46. A method for establishing a certification hierarchy, comprising:creating at least a first root key that has a validity range; creatingat least a first intermediate key that has a validity range; anddetermining if the range of the at least a first intermediate key iscontained within the validity range of the at least a first root key.47. The method of claim 46, further comprising: associating a trustlevel to a certificate signed by the at least a first intermediate keyif the range of the at least a first intermediate key is containedwithin the validity range of at least a first root key.
 48. The methodof claim 46, further comprising: associating an untrustworthy level to acertificate signed by the at least a first intermediate key if thevalidity range of the at least a first intermediate key is not containedwithin the validity range of the at least a first root key.
 49. Themethod of claim 46, further comprising: creating at least a firstduration key that has a validity range; and determining if the validityrange of the at least a first root key includes the validity range ofthe at least a first intermediate key; and determining if the validityrange of the at least a first intermediate key includes the validityrange of the at least a first duration key.
 50. The method of claim 49,further comprising: associating a trust level to a certificate signed bythe at least a first duration key if the validity range of the at leasta first root key includes the validity range of the at least a firstintermediate key and the validity range of the at least a first durationkey is included within the validity range of the at least a firstintermediate key.
 51. The method of claim 49, further comprising:denying a level of trust to a certificate signed by the at least a firstduration key if the validity range of the at least a first intermediatekey does not include the validity range of the at least a first durationkey or if the validity range of the at least a first root key does notinclude the validity range of the at least a first intermediate key. 52.A processor that executes instructions for multiple party signatures,the instructions comprising: establishing a range in which a certificateis valid based upon a plurality of signatures that have predeterminedranges; and monitoring the predetermined ranges and invalidating thecertificate upon expiration of at least one of the plurality ofpredetermined ranges of the plurality of signatures.